1 INTEGRATION OF MEDIA PLAYBACK COMPONENTS WITH AN INDEPENDENT 

2 TIMING SPECIFICATION 

3 TECHNICAL FIELD 

4 The present invention relates generally to media player hosting by a web browser. More 



5 particularly, the invention provides a system and method for integrating generic media playback 

6 components into a web browser and for negotiating playback state and rendering status between the 

7 browser and the media player. 

8 BACKGROUND OF THE INVENTION 



9 Conventional Internet browsers were designed mainly as text layout engines. Such browsers, 

10 therefore, are typically very limited in the ways in which they deliver multimedia content. As 

1 1 broadband Internet access becomes more widely available, however, multimedia playback of content, 

12 including, but not limited to video content and audio content, will become an increasingly important 

13 feature that an Internet browser should provide. 

14 Conventionally, upon encountering an embedded multimedia object, a browser merely 



15 provides a rendering area and does not stay involved with communicating timing information to a 

16 media player or passing synchronization information between a media player and other types of 

1 7 content. Instead, with respect to timing, the media player is essentially autonomous once it has been 

18 instantiated, and provided a rendering area, from a browser. 

19 Accordingly, there is a need in the prior art for increased communication between media 

20 players and browsers such that a browser is capable of knowing when a player has finished 

2 1 downloading content, when the player is ready to playback content, what the player's time rate is, and 

22 the like. In addition, there is a need in the prior art for allowing a browser to be capable of causing a 
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1 media player to perform various timing and synchronization-related operations, including, but not 

2 limited to commanding the player to start, stop, and pause playback, and to speed up and/or slow 

3 down media playback in accordance with any elements with which a media player's playback is to be 

4 synchronized. There is also a need in the prior art for seamlessly integrating content from various 

5 disparate sources, which may require various disparate media players, in accordance with a generic 

6 set of interfaces for exchanging information, including, but not limited to, timing and synchronization 

7 information, between browsers and media players. 

8 Accordingly, there is a need in the prior art for techniques that enable generic multimedia 

9 hosting by Internet browsers, whereby the browser becomes an improved platform for delivering 

10 media rich content in conjunction with text content, thereby allowing for a tighter integration of 

1 1 multimedia content into web content. 

12 SUMMARY OF THE INVENTION 

13 A system and method in accordance with certain inventive principles overcomes the foregoing 

14 shortcomings of the relatively limited interaction, and lack of exchange of timing and synchronization 

15 information, between prior art browsers and media players. 

16 In accordance with certain inventive principles, a software framework is provided that allows 

1 7 seamless integration of third party media players into a web browser. A media player includes, but is 

18 not limited to, a software module that implements any of various interfaces in accordance with the 

1 9 teachings of this invention. 

20 In accordance with the principles of the invention, a software architecture is provided that 

21 allows an Internet browser to host a generic media player. A "media player" may be any software 
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1 component that defines a playing state, such as playing, paused, stopped, and the like, and associates 

2 with that playing state a current playback time. The current playback time may be the time offset into 

3 the media at which the player is currently playing. 

4 Various inventive principles include a generic description of a media player and provision of 

5 one or more of the following services to media players: layout and composition of the rendering area 

6 the player renders to; scheduling of downloads and presentation times; and synchronization of media 

7 playback with a timing representation provided by the browser. These services make web browsing a 

8 more robust and versatile medium for multimedia delivery. 

Q 9 In accordance with certain inventive principles, techniques are provided for allowing 

'^/i 10 integration of any media player that supports certain specifics, which have been integrated into a web 

: 11 browser's rendering architecture and timing architecture. According to various aspects of the 

I fS 12 invention, a mechanism is provided for dynamically adjusting the rate of timing flow between different 

0 13 playback components, 

P 14 In accordance with certain inventive principles, a media player preferably implements various 

15 interfaces, inchiding, but not limited to the following types of interfaces, which are described in more 

1 6 detail below: player lifetime management interface; timing mterfaces, which may be used to exchange 

17 timing information between content, the media player, and a browser hosting the player; playback 

1 8 control interfaces, which may be used to control media playback; rendering interfaces, which may be 

19 used by rendering media players to render media content; and playback synchronization interfaces, 

20 which may be used to communicate timing information between a media player and a web browser. 

2 1 While the player lifetime management interfaces, playback control interfaces, and rendering interfaces 
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1 are generally directed toward object management, the timing interfaces and playback synchronization 

2 interfaces allow for timing synchronization of multimedia content. 

3 As described in more detail below, under certain circumstances, the playback synchronization 

4 interfaces may allow a host computer to provide timing information to content present in an HTML 

5 page. These interfaces provide methods that allow multiple media players present on a page to 

6 synchronize with each other or with other timed content. 

7 In accordance with certain inventive principles, media player hosting is managed by a 

8 component, referred to as a player-hosting peer, which will typically be implemented in software and 

9 built into a web browser. The peer preferably negotiates playback state and rendering status between 

10 the browser and the player. The player-hosting peer and media player preferably perform state 

11 transitions described in detail below to keep a web browser and one or more media players 

12 coordinated and synchronized while displaying or rendering multiple potentially disparate types of 

13 content that may be incorporated into a single document. 

1 4 In accordance with various inventive principles, communication channels for informing media 

15 playback components about a browser's timing infrastructure are provided. A web content author 

16 may use different embeddable playback components, each having different notions of time, within a 

17 single document at the author's discretion. 

18 According to certain inventive aspects, an infrastructure, referred to as a proxy layer or 

1 9 mtegration layer, is provided that underlies, and allows extensibility of, various elements set forth in 

20 the working draft of the SMIL 2.0 Timing and Synchronization Module, The working draft of the 

2 1 SMIL 2.0 Timing and Synchronization Module discusses in detail the use of special temporal models, 
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1 including, for instance, the expected consequences of declarations, such as sync master and other 

2 synchronization behaviors. A media player may be either native to a browser or may be an external 

3 media player. An external media player is advantageously able to integrate seamlessly into a browser 

4 by implementing certam interfaces in accordance with various principles of the invention. The proxy 

5 layer extends the timing and synchronization functionality existing in the context of a browser and 

6 native media player to the context of a browser and a media player that is external to the browser. 



7 Additional features and advantages of the invention will be apparent upon reviewing the 

8 following detailed description. 

9 BRIEF DESCRIPTION OF THE DRAWINGS 

10 Figure 1 is a schematic block diagram of a conventional general-purpose digital computing 

1 1 environment that can be used to implement various aspects of the present invention. 

12 Figure 2 is a simplified block diagram showing a web browser, a native media player, and a 

13 player-hosting peer in accordance with various inventive principles. 

14 Figure 3 is a state transition diagram for a player-hosting peer in accordance with various 

1 5 inventive principles. 

16 Figure 4 is a state transition diagram for a generic media player in accordance with various 

1 7 inventive principles. 

18 Figure 5 is a table showing correspondence between various player-hosting peer states and 

19 media player states. 

20 Figure 6 is a table providing a description of various commands and events that may trigger 

21 player-hosting peer state changes. 
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1 Figure 7 is a simplified block diagram, similar to Figure 2, showing a web browser, player- 

2 hosting peer, proxy layer, and an external media player in accordance with various inventive 

3 principles. 

4 DETAILED DESCRIPTION OF THE INVENTION 

5 Introduction 

6 In accordance with certain inventive principles, a software framework is provided that allows 

7 for seamless integration of media players into a web browser. A media player includes, but is not 

8 limited to, a software module that implements any of various interfaces described below. Various 

9 inventive principles include a generic description of a media player and provision of one or more of 

10 the following services to media players: layout and composition of the rendering area the player 

1 1 renders to; scheduling of downloads and presentation times; and synchronization of media playback 

12 with a timing representation provided by the browser. These services make web browsing a more 

1 3 versatile medium for multimedia delivery, 

14 In accordance with certain inventive principles, techniques are provided for allowing 

15 integration of any media player that supports certain specifics that have been integrated into a web 

16 browser's rendering architecture and timing architecture. 

17 Conventional views of content historically have been that the media itself is self-contained 

1 8 such that everything that is part of the presentation is part of the single component. In accordance 

19 with certain principles of this invention, a more open view of content is provided to allow a richer 

20 type of integration and communication to occur between one or more media streams, playback 

21 components, and/or other system components. Accordingly, integration may occur between various 
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1 disparate types of content such as simple text content and one or more disparate corresponding media 

2 players, 

3 According to an aspect of the invention, a mechanism is provided for dynamically adjusting 

4 the rate of timing flow between different playback components. 

5 In the web community, taking information and raw content from other sources and 

6 aggregating the information and/or raw content is becoming increasingly popular. In some 

7 circumstances, entities that re-package the information have rights to distribute the content, but not to 

8 modify the content itself Under these circumstances, the ability to seamlessly integrate such content 
,S 9 with other content and to tailor the integrated content to a re-packager*s desires takes on increased 
' J 10 importance. Accordingly, there is a need in the prior art for improved techniques for allowing 
m 1 1 seamless repackaging and re-purposing of such information. 

; 12 For instance, specific types of media streams may have triggers embedded in them. These 

^Ij 13 constructs are typically used in advertising. HTML content may be synchronized v^h particular 

ill 14 events in media content. For instance, advertisements, in the form of HTML content, may be 

I 1 5 synchronized vAth multimedia content such as products shown in a movie. An HTML advertisement 

I 

I 1 6 may be displayed next to a movie during the portion of the movie that shows the advertised product. 



ii 

11 



17 The advertisement may include a link allowing a user to obtain information about the product and/or 

3 1 8 to purchase the product. A web-page author could specify in HTML that the media content should 

i| 19 pause automatically upon a user following a link in such an advertisement. Such an integration of 

=1 20 multimedia content, in the form of video content, may be used to particular advantage in the context 

i| 

ll 21 of a web browser running in a cable television set top environment, for instance. In such a context, a 

i| 



at 

i 



MS 142424.1 BW 03797.00029 



mil ii\ 



« 

i 



i 



■ 

i! 



1 browser may be used as a viewer for selecting movies, television shows, pay-per-view events, and the 

2 like, using an Internet back channel. 

3 Another example of integrating multimedia content is combining the slides of a 

4 "POWERPOINT" graphics program presentation with recorded video of a presentation based on the 

5 "POWERPOINT" program slides. The slides may be synchronized to specific moments in the 

6 presentation to which the slides correspond. These two types of content may be integrated on a 

7 single page and played back in synchronization by a video player and a "POWERPOINT" player in 

8 accordance with the teachings of this invention. 

9 Conventional General-Purpose Digital-Computing Environment 

10 Figure 1 is a schematic diagram of a conventional general-purpose digital-computing 

1 1 environment that can be used to implement various aspects of the present invention. A computer 100 

12 includes a processing unit 110, a system memory 120 and a system bus 130 that couples various 

13 system components including the system memory to the processing unit 110. The system bus 130 

14 may be any of several types of bus structures including a memory bus or memory controller, a 

15 peripheral bus, and a local bus using any of a variety of bus architectures. The system memory 120 

16 includes a read only memory (ROM) 140 and a random access memory (RAM) 150. 

17 A basic input/output system (BIOS) 160 containing the basic routines that help to transfer 

18 information between elements within the computer 100, such as during start-up, is stored in ROM 



ill 

ij 19 140. Computer 100 also includes a hard disk drive 170 for reading from and writing to a hard disk 



20 (not shown), a magnetic disk drive 1 80 for reading from or writing to a removable magnetic dsk 190, 

21 and an optical disk drive 191 for reading from or writing to a removable optical disk 192, such as a 
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1 CD ROM or other optical media. Hard disk drive 170, magnetic disk drive 180, and optical disk 

2 drive 191 are respectively connected to the system bus 130 by a hard disk drive interface 192, a 

3 magnetic disk drive interface 193, and an optical disk drive interface 194, The drives and their 

4 associated computer-readable media provide nonvolatile storage of computer readable instructions, 

5 data structures, program modules and other data for the computer 100. It will be appreciated by 

6 those skilled in the art that other types of computer readable media which can store data that is 

7 accessible by a computer, such as magnetic cassettes, flash memory cards, digital video disks, 

8 Bernoulli cartridges, random access memories (RAMs), read only memories (ROMs), and the like, 

9 may also be used in the exemplary operating environment. 

10 A number of program modules can be stored on the hard disk, magnetic disk 1 90, optical disk 

11 192, ROM 140 or RAM 1 50, including an operating system 1 95, one or more application programs 

12 196, other program modules 197, and program data 198. In particular, the RAM 150 will, from time 

13 to time, store various device drivers, as known in the art. A user can enter commands and 

14 information into computer 100 through input or selection devices, such as a keyboard 101 and a 

1 5 pointing device 1 02 . The pointing device 1 02 may comprise a mouse, touch pad, touch screen, voice 

16 control and activation or other similar devices. Other input devices (not shown) may include a 

1 7 microphone, joystick, game pad, satellite dish, scanner, or the like. These and other input devices are 

1 8 often connected to the processing vinit 1 1 0 through a serial port interface 1 06 that is coupled to the 

19 system bus, but may be connected by other interfaces, such as a parallel port, a game port or a 

20 universal serial bus (USB). A monitor 107 or other type of display device is also connected to system 
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1 bus 1 3 0 via an interface, such as a video adapter 1 08 . In addition to the monitor, personal computers 

2 typically include other peripheral output devices (not shown), such as speakers and printers. 

3 An IEEE 1394 interface 140 may also be provided. The DEEE 1394 interface 140 couples an 

4 IEEE 1394-compliant serial bus 145 to the system bus 130 or similar communication bus. The IEEE 

5 1394-compliant serial bus 145, as known in the art, allows multiple devices 150 to communicate with 

6 the computer 100 and each other using high-speed serial channels. The IEEE 1394 serial bus 

7 standard is based largely upon the internationally adopted ISO/IEC 13213 (ANSI/IEEE 1212) CSR 

8 Architecture Specification and the DEEE 1 394- 1 995 Serial Bus Specification, the teachings of which 

9 are herein incorporated by reference. Additional buses such as the PCI bus can be provided in 

10 computer 100 and interfaced to the IEEE 1394 and other buses. 

11 A typical serial bus having an IEEE 1 3 94 standard architecture is comprised of a multiplicity 

12 of nodes that are interconnected via point-to-point links, such as cables, that each connect a single 

1 3 node of the serial bus to another node of the serial bus. The nodes themselves are addressable entities 

14 that can be independently reset and identified. Nodes are logical entities, each with a unique address. 

1 5 Each node provides a so-called configuration ROM (read-only memory)— hereinafter referred to as 

16 configuration memory-and a standardized set of control registers that can be accessed by software 

1 7 residing within the computer system. 

1 8 The computer 1 00 can operate in a networked environment using logical coimections to one 

19 or more remote computers, such as a remote computer 109, The remote computer 109 typically 

20 includes at least some of the elements described above relative to the computer 100, although only a 

21 memory storage device 1 1 1 has been illustrated in FIG. 1 . The logical connections depicted in FIG. 1 

MS 142424.1 BW 03797.00029 

10 



mm If ' /II 



1 include a local area network (LAN) 1 12 and a wide area network (WAN) 113. Such networking 

2 environments are commonplace in offices, enterprise-wide computer networks, intranets and the 

3 Internet. 

4 When used in a LAN networking environment, the computer 100 is connected to local 

5 network 112 through a network interface or adapter 114. When used in a WAN networking 

6 environment, the computer 100 and remote computer 109 may both include a modem 1 15 or other 

7 means for establishing a communications over wide area network 113, such as the Internet. The 

8 modem 115, which may be internal or external, is connected to system bus 130 via the serial port 

9 interface 1 06. In a networked environment, program modules depicted relative to the computer 100, 

10 or portions thereof, may be stored in the remote memory storage device. 

1 1 It will be appreciated that the network connections shown are exemplary and other means of 

12 establishing a communications link between the computers can be used. The existence of any of 

13 various well-known protocols, such as TCP/IP, "ETHERNET", FTP, HTTP and the like, is 

1 4 presumed, and the system can be operated in a client-server configuration to permit a user to retrieve 

1 5 web pages from a web-based server. Procedures of the present invention to be described below can 

16 operate within the environment of the computer 100 shown in FIG. 1. Although the invention is 

17 generally applicable to a computer operating in accordance with the IEEE 1394 standard, it is not 

1 8 intended to be so limited. 

1 9 Media Players Generally 

20 In accordance with the principles of the invention, a software architecture is provided that 

21 allows an Internet browser to host a generic media player, A "media player" may be any software 
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1 component that defines a playing state, such as playing, paused, stopped, and the like, and associates 

2 with that playing state a current playback time. The current playback time may be the time offset into 

3 the media at which the player is currently playing. 

4 A media player may be either a rendering media player or a non-rendering media player. 

5 Rendering players are players that typically draw or display media content to a display or screen area. 

6 Non-rendering players typically do not display media content to such a screen area. An audio player, 

7 for instance, is an example of a non-rendering media player. 

8 A media player may also be either native to a browser or may be an external media player. An 

9 external media player may also be referred to as a thu-d-party media player. Such external or third- 

1 0 party media players are advantageously able to integrate seamlessly into a browser by implementing 

1 1 interfaces in accordance with various principles of the invention. Generally, most concepts discussed 

12 below are phrased in terms of media players, not specifically native players versus external players. If 

13 the term media player is used without the terms "native," "external," or "third-party," then the 

14 concepts being discussed generally apply to both types of media players, that is, both native media 

1 5 players and extemal/third-party media players. The proxy layer, also referred to as the integration 

16 layer, generally applies to external media players. The proxy layer extends the timing and 

17 synchronization fimctionality existing in the context of a browser and a native media player to the 

18 context of a browser and an external third-party media player. 

19 Media Player Interfaces 

20 In accordance with certain inventive principles, a media player preferably implements various 

21 interfaces, including, but not limited to the following types of interfaces, which are described in more 
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1 detail below: player lifetime management mterface; timing interfaces, which may be used to exchange 

2 timing information between content, the media player, and a browser hosting the player; playback 

3 control interfaces, which may be used to control media playback; rendering interfaces, which may be 

4 used by rendering media players to render media content; and playback synchronization interfaces, 

5 which may be used to communicate timing information between a media player and a browser. While 

6 the player lifetime management interfaces, playback control interfaces, and rendering interfaces are 

7 generally directed toward object management, the timing interfaces and playback synchronization 

8 interfaces allow for improved synchronization of multimedia content. As will be apparent, although 

9 the plural term "interfaces" is used throughout this document, this term may refer to one or more 

10 interfaces without departing from the scope and spirit of the present invention. 

1 1 The player lifetime management interfaces may be used to manage media player components. 

12 For instance, these interfaces may contain methods that are used to create and/ or destroy a media 

1 3 player. Methods that facilitate the negotiation of services required by the player may also be provided 

14 within these interfaces. 

1^ The timing interfaces may provide methods that expose and control timing specific states 

1 6 defined by a media player. These may include methods that retrieve a player's current playback time. 

1 7 Media playback may be controlled through the playback control interfaces. Generally stated, 

1 8 a player may be started, stopped, paused, resumed, or seeked to a given time offset. The player may 

19 inform the host of its playback capabilities through a set of capabilities methods. 

20 The rendering interfaces may define methods used to set up various rendering mechanisms 

2 1 negotiated with the media player component by a host computer. 
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1 As described in more detail below, under certain circumstances, the playback synchronization 

2 interfaces may allow a host computer to provide timing information to content present in an HTML 

3 page. These interfaces provide methods that allow multiple media players present on a page to 

4 synchronize with each other or with other timed content. 

5 Types of Player Hosting 

6 Player hosting may be non-scheduled, scheduled, or synchronized. Non-scheduled hosting 

7 will typically be triggered by user interaction or some other host-initiated event and will typically have 

8 the player starting playback as soon as the player's media downloads. One example of this type of 

9 scenario already implemented by existing browsers is an animated .gif, which plays back as soon as it 
1 0 loads. In accordance v^th certain inventive principles, any type of media content may be hosted in a 



1 1 similar manner, 

12 In a scheduled hosting scheme, media playback may be scheduled to begin at a time provided 

13 by a web content author. The media is preferably preloaded in an attempt to minimize the effect that 

14 download times have on the overall behavior of timed web content. 

15 In a synchronized scheme, constraints are typically imposed on time relationships that exist 

16 between different timed content present on the same web page. 

1 7 Player-Hosting Peer 

1 8 Referring to Figure 2, in accordance with certain inventive principles, media player hosting is 

19 managed by a component, referred to as a player-hosting peer 200, which will typically be 

20 implemented in software and built into a web browser 202. 
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1 The peer preferably negotiates playback state and rendering status between the browser 202 

2 and the player 204. Both the player and its peer preferably maintain playing state and current 

3 playback time. The relationship between the peer and the player is preferably a master slave 

4 relationship, with the peer being the master. The peer may issue comnxands 206 to the player, while 

5 the player may notify the peer of any state changes 208. 

6 Figure 3 is a simplified state transition diagram showing example states through which the 

7 player-hosting peer 200 may transition. Figure 4 is a simplified state transition diagram showing 

8 examples states through which the player 204 may transition. The state of the player-hosting peer 
, . I 9 typically restricts the possible states that the player can be in. Figure 5 is a table that shows a typical 

10 correspondence between certain peer and player states, 

y ; 1 1 Player Peer State Transition Diagram 

'4 12 The arcs connecting the state nodes shown in Figure 3 represent events or commands issued 

13 by either the hosting browser 202 or the player 204. The peer 200 acts as a component that 

\^ 14 negotiates interaction between the browser and the player. The peer abstracts behavior that is specific 

ij 15 to neither the player nor the browser. Figure 6 is a table containing short descriptions of various 

16 events and/or commands that may trigger state changes in the peer, 

17 Referring to Figures 3 and 4, various example operations and state transitions will be 

18 described. It will be apparent that other suitable operations and state transitions could also occur 

19 without departing firom the scope of the invention. In accordance with certain inventive principles, 

20 the peer 200 is initialized in its Inactive state 300. After finishing its initialization, the peer may 
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1 instantiate the player 204. After the player is instantiated, the player may be initialized in the No 

2 Source state 400. 

3 The peer may perform a Media Cued transition 3 02 from the Inactive state 3 00 to the Active 

4 state 304 as follows: the peer 200 may wait in the Inactive state 300 for the player 204 to build any 

5 desired infrastructures. When the browser 202 sets a source, the player 204 may first cue the media 

6 to be played. Media cueing may include source connection operations performed before the media 

7 source becomes accessible. Upon media cue completion, the player may make a Media Cued 

8 transition 402 from the No Source state 400 to the Playing state 404. The player will typically be 

9 ready to playback media from the Playing state 404. The peer's Media Cued transition 302 to the 

1 0 Active state 3 04 preferably occurs as a result of the player's Media Cued transition 402 to the Playing 

1 1 state 404. 

12 From the Active state 304 the player peer 200 may transition to any of the following states: 

13 Out of Sync 306, Waiting for Data 308, and Inactive 300. 

1 4 When the player 204 is hosted with a synchronized hosting scheme, the Out of Sync state 306 

15 may be entered if the player 204 loses timing synchronization with its hosting peer 200. 

1 6 Synchronization loss is detected by the peer 200, which also notifies the player 204 of the peer's Sync 

1 7 Lost transition 3 1 0 to the Out of Sync state 3 06. The hosting peer 200 may try to resolve the "out of 

18 sync condition" by using heuristics applied to both its own timing and the player's timing. If the 

19 player's peer 200 detects that resynchronization has occurred, the peer performs a Sync Recovered 

20 transition 3 12 from the Out of Sync state 306 back to the Active state 304. A Seek transition 3 14 
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1 from the Out of Sync state 306 to the Active state 304 may also occur as the resuh of an attempt to 

2 seek the media. 

3 The player peer 200 may perform Bufier Empty transitions 3 1 6 and 3 1 8 from the Active and 

4 Out of Sync states 304 and 306, respectively, to the Waiting for Data state 308 when the player 204 

5 can no longer playback media due to a buffer empty problem or any other media delivery problem. 

6 Buffer Empty transition 316 from the Active state 304 to the Waiting for Data state 308 may be 

7 initiated by the player 204 and may be signaled to the player-hosting peer 200. When the player 204 

8 can no longer play due to an insufficient amount of buffered data, synchronization can no longer be 

9 recovered until the player has enough data to resume playback. When sufficient data is available for 

10 the player to continue playback, the player peer 200 may perform a Bufier Full transition 320 from 

1 1 the Waiting for Data state 3 08 back to the Active state 3 04. While the player-hosting peer 200 is in 

12 the Waiting for Data state 308, a seek command from the browser 202 to the player-hosting peer 200, 

13 will result in a Seek transition 322 to the Active state 304. Such a Seek transition 322 may be 

14 performed when a timing constraint affecting sync between the player-hosting peer 200 and the player 

1 5 204 exists. Following such a Seek transition 322, if the player has insufficient buffered data, a Buffer 

16 Empty transition 3 16 is performed from the Active state 304 back to the Waiting for Data state 308. 

17 Upon buffering of a sufficient amount of data, a Buffer Full transition 320 is performed from the 

18 Waiting for Data state 308 to the Active state 304. 

19 If the player source is changed, the new media source typically needs to be cued before 

20 playback can resume. Under such a scenario, the peer 200 may perform a Change Source transition 

2 1 324 from the Active state 304 to the Inactive state 300, and the player 204 may perform a Change 
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1 Source transition 406 from the Playing state 404 to the No Source state 400. The peer 200 may 

2 perform a Deactivate transition 326 from the Active state 304 to the Inactive state 300 when the 

3 player should be shutdown and removed. The browser may initiate such a Deactivate transition. 

4 Player State Transition Diagram 

5 After creation and initialisation of the player 204, the player will typically start in the No 

6 Source state 400. Upon successful completion of media cueing, which occurs after a media source is 

7 set on the player, the player performs a Media Cued transition 402 from the No Source state 400 to 

8 the Playing state 404. In the Playing state, the player may be either running or paused. Setting a 

9 media source on the player will typically initiate a Change Source transition 406 to the No Source 

10 state 400 from the Playing state 404. 

1 1 The player 204 may perform a Stop transition 408 from the Playing state 404 to the Media 

12 Done state 410 upon receiving a stop command from the player peer 200, Similarly, the player 204 

1 3 may perform a Finished Media Playback transition 4 1 2 from the Playing state 404 to the Media Done 

14 state 410 upon playing particular content to the end of that content, A rendering media player may 

1 5 use the Media Done state 4 1 0 for rendering a last frame of content. Upon receiving a start command 

1 6 from the player-hosting peer 200, the player 204 may perform a Start transition 4 1 4 from the Media 

1 7 Done 4 1 0 state to the Playing 404 state. 

18 Upon receiving a seek command from the player-hosting peer 200, the player 204 may 

19 perform a Seek transition 416 from the Playing state 404 to the Seeking state 418. Upon completing 

20 the seek operation, the player 204 may perform a Seek Done transition 420 from the Seeking state 

21 41 8 to the Playing state 404. 
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Integration or Proxy Layer 

The proxy layer allows external media players to integrate seamlessly into a browser by 
implementing a relatively limited number of interfaces in accordance with various principles of the 
invention. The proxy layer extends the timing and synchronization functionality, discussed above, 
that exists in the context of a browser and native media player to the context of a browser and an 
external media player. Referring to Figure 7, proxy layer 700 receives commands 702 from player 
hosting peer 200 and sends commands 704 to an external media player 706. Proxy layer 700 also 
receives state changes and/or other synchronization information 708 from the external media player 
706 and sends state changes and/or other synchronization information 7 1 0 to the player-hosting peer 
200. 

According to various inventive principles, the commands 702 and 704 and the state changes 
708 and 710 may be passed between the player hosting peer 200, proxy layer 700 and external media 
player 706 via the following interfaces: 

ITIMEMediaPlayerSite: this interface is implemented by the hosting peer 200 
and provides access to timing information available from the hosting peer; 

ITIMEMediaPlayer: this interface is implemented by the external player 706 
and contains the methods the player 706 implements for integrating with the browser 
202; 

ITIMEMediaPlayerControl: this interface is implemented by the external 
player 706 and allows the player 706 to declare itself an OLE compliant ActiveX 
control. Rendering media players preferably make such a declaration. If a player 
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1 does not need rendering support, the player can disable ActiveX support on the peer 

2 side thereby reducing the use of CPU time and memory resources. 

3 These interfaces advantageously shield developers of external media player from having to deal with 

4 synchronization details, which are handled by the player-hosting peer. Example interface definitions 

5 are set forth below. As will be apparent other suitable interface definitions could also be used without 

6 departing fi-om the spirit and scope of the invention. 



7 [ 

8 object, 

9 uuid(bfD571ed-344f-4£58-82c7-743 Ied0fd834), 

10 pointer_default(unique) 

11 ] 

12 interface ITIMEMediaPlayerSite : lUnknown 

13 { 

14 [propget, id(DISPID_TIMEMEDIAPLAYERSITE_TIMEELEMENT)] 

15 HRESULT timeElement([out, retval] ITlMEElement ** pEhn); 
16 

17 [propget, id(DISPID_TIMEMEDIAPLAYERSITE_TIMESTATE)] 

18 HRESULT timeState([out, retval] ITIMEState ** pState); 
19 

20 [id(DISPID_TIMEMEDIAPLAYERSITE_REPORTERROR)] 

21 HRESULT reportError([in] HRESULT hr, 
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1 [in] B STR errorString); 

2 } 
3 

4 [ 

5 object, 

6 uuid(ea4a95be-acc9-4bf0-85a4- Ibf3c5 1 e43 1 c), 

7 pomter_default(umque) 

8 ] 

2 9 interface ITIMEMediaPlayer : lUnknown 

3 10 { 

^[ll [id(DISPIDjriMEMEDIAPLAYERJNIT)] 

J 12 HRESULT Imt(ITIMEMediaPlayerSite * mpsite); 

3 13 [id(DISPID_TIMEMEDIAPLAYER_DETACH)] 

5 14 HRESULT DetachQ; 

3l5 

16 [id(DISPID_TIMEMEDIAPLAYER_BEGIN)] 

17 HRESULT beginO; 

18 [id(DISPID_TIMEMEDL\PLAYER_END)] 

19 HRESULT endQ; 

20 [id(DISPID_TIMEMEDIAPLAYER_RESUME)] 

21 HRESULT resumeQ; 
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1 [id(DISPID_TIMEMEDIAPLAYER_PAUSE)] 

2 HRESULT pauseQ; 

3 [id(DISPID_TIMEMEDIAPLAYER_REPEAT)] 

4 HRESULT repeatQ; 

5 [id(DISPID_TIMEMEDIAPLAYER_RESET)] 

6 HRESULT resetQ; 

7 [id(DISPID_TIMEMEDIAPLAYER_SEEK)] 

8 HRESULT seek([in] double time); 
9 

10 // Properties - w 

11 [propput, id(DISPID_TIMEMEDIAPLAYER_SRC)] 

12 HRESULT src([in] BSTR url); 

13 [propput, id(DISPID_TIMEMEDIAPLAYER_CLIPBEGIN)] 

14 HRESULT clipBegin([in] VARIANT b); 

15 [propput, id(DISPID_TIMEMEDIAPLAYER_CLIPEND)] 

16 HRESULT clipEnd([in] VARIANT e); 
17 

18 // Properties - r/o 

19 [propget, id(DISPID_TIMEMEDIAPLAYER_ABSTRACT)] 

20 HRESULT abstract([out, retval] BSTR *abs); 
21 
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1 [propget, id(DISPID_TIMEMEDIAPLAYER_AUTHOR)] 

2 HRESULT author([out, retval] BSTR *auth); 
3 

4 [propget, id(DISPID_TIMEMEDIAPLAYER_CANPAUSE)] 

5 HRESULT canPause([retval, out] VARIANT_BOOL * b); 
6 

7 [propget, id(DISPID_TIMEMEDIAPLAYER_CANSEEK)] 

8 HRESULT canSeek([retval, out] VARIANT_BOOL * b); 

4 10 [propget, id(DISProjriMEMEDIAPLAYERj:LIPDUR)] 

^ 1 1 HRESULT clipDur([out, retval] double * dur); 
3 12 

3 13 [propget, id(DISPID_TIMEMEDIAPLAYER_COPYRIGHT)] 

3 14 HRESULT copyright([out, retval] BSTR *cpyrght); 
3 15 

16 [propget, id(DISPID_TIMEMEDIAPLAYER_CURRTIME)] 

17 HRESULT currTime([out, retval] double * time); 
18 

19 [propget, id(DISPID_TIMEMEDIAPLAYER_CUSTOM_OBJECT)] 

20 HRESULT customObject([out, retval] Mspatch ** disp); 
21 
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1 [propget, id(DISPID_TIMEMEDIAPLAYER_HASAUDIO)] 

2 HRESULT hasAudio([retval, out] VARIANT_BOOL * b); 
3 

4 [propget, id(DISPID_TI]VIEMEDIAPLAYER_HASVISUAL)] 

5 HRESULT hasVisual([retval, out] VARIANTJBOOL * b); 
6 

7 [propget, id(DISPID_TIMEMEDIAPLAYER_MEDIADUR)] 

8 HRESULT mediaDur([out, retval] double *dur); 
9 

10 [propget, id(DISPID_TIMEMEDIAPLAYER_MEDIAHEIGHT)] 

1 1 HRESULT mediaHeight([out, retval] long *height); 
12 

13 [propget, id(DISPID_TIMEMEDIAPLAYER_MEDIAWIDTH)] 

14 HRESULT mediaWidth([out, retval] long *width); 
15 

16 [propget, id(DISPID_TIMEMEDIAPLAYER_PLAYLIST)] 

17 HRESULT playList([out, retval] ITIMEPlayList** pPlayList); 
18 

19 [propget, id(DISPID_TIMEMEDIAPLAYER_RATING)] 

20 HRESULT rating([out, retval] BSTR *rate); 
21 
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1 [propget, id(DISPID_TIMEMEDIAPLAYER_STATE)] 

2 HRESULT state([out, retval] TimeState * ts); 
3 

4 [propget, id(DISPID_TIMEMEDIAPLAYER_TITLE)] 

5 HRESULT title([out, retval] BSTR *name); 
6 

7 }; 

8 

9 [ 

10 object, 

1 1 uuid(897a99e7-f3 86-45c8-b5 Ib-3a25bbcbba69), 

12 pointer_default(unique) 

13 ] 

14 interface ITIMEMediaPlayerControl : lUnknown 

15 { 

16 [id(DISPID_TIMEMEDIAPLAYERCONTROL_GETCONTROL)] 

17 HRESULT getControl(IUnknowa ** control); 

18 } 

19 In accordance with various inventive principles, a web content author may use different 



20 embeddable playback components, each having different notions of time, within a single document at 

2 1 the author's discretion. According to certain inventive aspects, an infrastructure, also referred to as a 
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1 proxy layer or integration layer, is provided that underlies, and allows extensibility of, various 

2 elements set forth in the working draft of the SMIL 2.0 Timing and Synchronization Module (Exhibit 

3 A). The SMIL 2.0 Timing and Synchronization Module is part of the working draft of the SMIL 2.0 

4 specification, which is hundreds of pages long. 

5 For instance, video content may play with a browser's native media player, or a document 

6 author may specify a particular player to be instantiated. If the specified player implements the 

7 necessary interfaces, in accordance with the teachings of this invention, then that player, or any other 

8 player that implements the appropriate interfaces, will simply integrate with the browser. In this way, 

9 various disparate players, for various, possibly disparate, media, may be seamlessly integrated with 

10 various browsers in accordance with the teachings of this invention. In other words, any generic 

1 1 player that implements a set of interfaces in accordance with various principles of the invention will 

12 integrate seamlessly with a browser and will be able to exchange timing and synchronization 

13 information with other system components, such as a browser, and/or other timed content. 

14 DirectMusic, for instance, is a technology that allows for play back of music specified 

1 5 essentially in the form of written sheet music. So, instead of sampled music like " . wav" or analogous 

16 formats, the notes may be written and orchestration of various instruments and the like may be 

1 7 specified. A player that takes DirectMusic as a source may be used along with a DirectMusic source 

1 8 file thereby allowing playback of DirectMusic within a web browser. 

1 9 The DirectMusic time model is completely different than the typical simple duration model, 

20 which starts at time zero and progresses in standard units of time, such as seconds. DirectMusic may 

2 1 specify a cadence, a style of music, and the like. In accordance with the teachings of this invention, 
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1 an integration or proxy layer may be used to provide a reasonable mapping so that authors who want 

2 to use DirectMusic to augment their web pages are able to do so without having to ripple out a 

3 radically different timing universe to the world. Significantly, the integration or proxy layer allows a 

4 defined playback mechanism to coexist and also synchronize with more traditional textual types of 

5 media, 

6 Concluding Remarks 

7 What has been described above is merely illustrative of the application of the principles of the 

8 present invention. Those skilled in the art can implement other systems and methods without 

9 departing firom the spirit and scope of the present invention. Any of the methods of the invention can 

10 be implemented in software that can be stored on computer disks or other computer-readable media. 

11 No claim should be interpreted to be in means plus fiinction format. 
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